В блоге joshodgers.com появилось пять интересных статей о том, как правильно виртуализовать почтовый сервер Microsoft Exchange на платформе VMware vSphere.

Итак, что там интересного:

1. Part 1 – CPU Sizing.

Тут прелагается использовать утилиту Exchange 2013 Server Role Requirements Calculator v6.6 для определения требований к почтовому серверу:

2. Part 2 – vCPU Configurations.

В этой статье обсуждается необходимое число vCPU для виртуальной машины с Exchange.

Ничего необычного, в принципе, но стоит почитать.

3. Part 3 – Memory.

Тут обсуждается необходмый объем памяти. Не рекомендуется использовать Memory Overcommitment (то есть, часть ресурсов надо всегда держать свободными), а вот Memory Reservations предлагается устанавливать в 100% - таковы рекомендации для бизнес-критичного сервиса.

К выделенной памяти виртуальным машинам рекомендуется прибавлять как минимум 25% требуемой емкости памяти хоста ESXi. То есть, если у вас машина с 96 ГБ RAM, то хост должен иметь как минимум 128 ГБ физической памяти. Также рекомендуется сайзить машину с Exchange в пределах одного NUMA-узла.

4. Part 4 – DRS.

Тут основная рекомендация - держать машины с ролями MBX / MSR на одном хосте в целях быстродействия (средствами хост-групп), а также настроить их восстановление в случае сбоя также на один хост. Также уровень автоматизаци миграций ВМ в кластере рекомендуют выставить как "Fully Automated" (а Migration Threshold как 3).

5. Part 5 – High Availability (HA).

В этой части цикла описываются рекомендуемые настройки механизма VMware HA.

В этой статье, пожалуй, больше всего дается практических советов и рекомендаций по настройке VMware HA в кластере высокой доступности для виртуальных машин с Exchange на борту.

Как вы знаете, у компании VMware был такой продукт как vCenter Server Heartbeat, который защищал управляющий сервер vCenter от сбоя различных его компонентов и на различных уровнях. Некоторое время этот продукт был снят с производства, и теперь защиту vCenter от сбоев рекомендуется обеспечивать стандартными средствами платформы VMware vSphere.

Надо сказать, что обеспечение надежности сервера vCenter, работающего в виртуальной машине (а сейчас уже мало кто ставит его в физической), начинается с обеспечения доступности и дублирования компонентов, которые находятся "под ним", а именно: хост-сервер ESXi, источники питания, хранилища, сетевые подключения и т.п.

Ну а, собственно, для правильной конфигурации самой платформы vSphere и сервера vCenter, компания VMware выпустила полезный документ "VMware vCenter Server 5.5 Availability Guide".

Итак, начнем с того, что VMware предлагает разделить сервисы vCenter на две большие части:

• Compute Node - это сам vCenter и все сервисы к нему относящиеся (SSO, Web Client, Inventory service)
• Data Node - это узел, где хранятся данные vCenter, попросту говоря, это СУБД и сама база данных.

Понятно, что оба этих компонента могут быть как на одном сервере (для небольшой инфраструктуры), так и в разных машинах, когда требуется производительная база данных (например, в Enterprise-окружениях).

Если у вас большая виртуальная инфраструктура, где есть множество управляющих компонентов, то вы можете выделить отдельный кластер из трех и более хостов чисто под эти нужды.

Но чаще всего у вас есть просто одна или максимум две виртуальные машины - одна под vCenter, вторая - под его базу данных.

Доступность Compute Node

Это раздел включает в себя доступность следующих комопнентов:

• vCenter Single Sign-On services
• vCenter Inventory Service
• vCenter Server
• vCenter Server management Web service
• vSphere Web Client

Здесь рекомендуется настроить защиту средствами технологии VMware HA и придерживаться следующих рекомендаций:

• Создавайте (по-возможности) отдельный кластер для управляющих сервисов - в случае отказа любого из компонентов сервисы будут перезапущены с помощью HA автоматически.
• Включите не только VMware HA, но и технологию virtual machine monitoring, которая отключена по умолчанию. Это позволит перезапустить сервер с vCenter при зависании гостевой ОС.

• Включите и настройте admission control в кластере HA/DRS, где работает vCenter. Это позволит гарантированно перезапустить vCenter на одном из хостов в случае сбоя.
• Установите restart priority в настройках HA для машины с vCenter Server в значение "High". Он будет первым запускаться.
• Если ваш vCenter находится в Windows-машине, то можно настроить автоматический рестарт машины при невозможности после многократных попыток запустить службу vCenter Service.

Выглядеть это может примерно вот так (только помните, что в случае такй настройки, виртуальная машина может впасть в цикл бесконечных перезагрузок).

• Если у вас компоненты vCenter на разных машинах, не забудьте установить правило affinity rule, чтобы машины оказались на одном хосте при миграции и восстановлении, в целях сохранения максимальной производительности управляющего сервиса.
• Также для гарантии можно выделить управляющим компонентам гарантированную физическую память (Memory Reservation) в настройках виртуальной машины.

Доступность Data Node

Тут VMware приводит следующие рекомендации:

• Также, как и в случае с Compute Node, рекомендуется использовать для управляющих сервисов и базы данных отдельный кластер.
• Если вы используете решение для кластеризации vCenter, необходимо убедиться, что настройка ForceAffinePoweron в параметрах vSphere DRS установлена в значение 1, чтобы включать сервер БД, несмотря на правила DRS.
• Так же, как и в случае с Compute Node, используйте технику virtual machine monitoring для перезапуска зависшей гостевой ОС.
• То же самое и про admission control - используйте его для гарантированного восстановления ВМ с сервером БД.
• Аналогично Compute Node, установите restart priority в настройках HA для машины с базой данных в значение "High". Он будет первым запускаться.
• Для защиты vCenter Server SQL Server database можно использовать Microsoft Failover Clustering, который официально поддерживается со стороны VMware. Табличка совместимости СУБД и версий vCenter приведена ниже.

О том, как восстанавливать серверы vCenter, и многом другом можно почитать в документе "VMware vCenter Server 5.5 Availability Guide".

На конференции TechEd Europe 2014 компания Microsoft не только сделала несколько интересных анонсов, касающихся облачной платформы Azure, но и выпустила занимательный документ "Windows Server Technical Preview Step-by-Step Guide Storage Quality of Service".

Напомним, что в новой версии платформы Windows Server vNext от компании Microsoft появится механизм Storage Quality of Service (QoS) - возможность динамического отслеживания производительности хранилищ и горячая миграция виртуальных машин при превышении этими хранилищами пороговых значений (IOPS). Все это делается на базе заранее настроенных политик. По-сути, это аналог механизма Storage DRS от компании VMware в продукте vSphere.

В этом документе от Microsoft на 16 страницах объясняется работа механизма Storage QoS и как его использовать для мониторинга производительности хранилищ и выравнивания нагрузки (забавное понятие "Noisy neighbor mitigation").

Содержание документа:

• Summary
• Goals & Behaviors
• Background
• Scenario 1: Enabling Storage QoS and basic performance monitoring
• Scenario 2: Creating and monitoring with policies
• Known Issues

Новая архитектура сервисов управления VMware vCenter в VMware vSphere 6.

Некоторое время назад мы писали о новых возможностях платформы виртуализации VMware vSphere 6, о которых было подробно рассказано на прошедшей конференции VMworld 2014. Одним из нововведений новой версии станет новая архитектура сервисов управления VMware vCenter.

Надо начать с того, что "толстый" десктопный клиент vSphere Client в vSphere 6 по-прежнему останется доступен для управления виртуальными машинами через vCenter. Причины просты - компании VMware так и не удается довести до ума Web Client - он все еще притормаживает и не настолько быстро обновляет статус объектов, как это делает обычный vSphere Client. Однако все новые возможности будут появляться только в vSphere Web Client.

С точки зрения самого vCenter появляется новый сервис Platform Services Controller (PSC), который заменяет существующие сервисы Single Sign-On (напомним, что они уже были переписаны в версии SSO 5.5). Если ранее SSO был частью vSphere и обновлялся только вместе с платформой, то теперь PSC может быть обновлен отдельно (например, если появились новые источники аутентификации или были исправлены ошибки), что очень удобно.

На картинке ниже Infrastructure Controller (это так сейчас в бете называется Platform Services Controller) может быть выделен для каждого сервиса vCenter, но также и несколько сервисов vCenter могут использовать один PSC.

В обоих случаях сохраняются функции синхронизации данных между контроллерами и механика их отказоустойчивости.

Помимо стандартных функций аутентификации SSO, компонент PSC возьмет на себя управление лицензиями, а также хранение сертификатов.

Когда у вас до 8 серверов vCenter в рамках одной географической площадки, то можно использовать один PSC (который устанавливается на том же хосте, где и один из серверов vCenter). Ну а если у вас несколько датацентров, то для каждого разумнее использовать свой PSC, к которому подключаются не только сервисы vCenter, но и другие компоненты виртуальной инфраструктуры, например, продукт для управления облачной инфраструктурой VMware vCAC или средства автоматизации vRealize Orchestrator (бывший vCenter Orchestrator):

Шестую версию vCenter уже настоятельно рекомендуют устанавливать в виртуальной машине, так как только тогда можно будет воспользоваться преимуществами технологий отказоустойчивости и непрерывной доступности VMware HA и VMware Fault Tolerance. Ранее был продукт и для физических серверов - vCenter Heartbeat, но его сняли с производства.

Настало время объединить все сервисы управления виртуальной средой (vCenter, серверы vCAC, vCenter Log Insight, vCenter Orchestrator, vCenter Operations Manager и т.п.) в виде блоков в виртуальных машинах:

Также весьма существенно будет доработан виртуальный модуль vCenter Server Appliance (vCSA). Теперь он будет поддерживать до 1 000 серверов ESXi под своим управлением, 10 000 включенных виртуальных машин, 64 хоста ESXi на кластер HA/DRS, 6 000 ВМ в кластере, а также 10 серверов vCenter в режиме Linked Mode.

Как многие из вас знают, ранее режим Linked Mode не поддерживался со стороны vCSA, так как для этого режима использовалась модель Active Directory Application Mode (ADAM), не поддерживаемая в Linux. Теперь для Linked Mode используется собственная аутентификация, поэтому объединение нескольких машин vCSA в единую мета-сущность теперь вполне возможно.

Как Windows-версия, так и vCSA будут использовать встроенную БД vPostgres, а в качестве внешних БД стандартно будут поддерживаться Microsoft SQL Server и Oracle.

Ну и, помимо всего прочего, сейчас ходят слухи о выпуске вместе с VMware vSphere 6 утилиты для миграции с Windows-версии vCenter на vCSA. Эта штука для многих пользователей будет очень кстати.

Если вы хотите, чтобы никто не делал vMotion конкретной виртуальной машины с конкретного сервера VMware ESXi, то нужно просто разослать письмо администраторам vSphere с просьбой этого не делать. Но есть еще один способ, который поведал нам Frank Denneman - хотя он тоже имеет ограниченные условия применения. Ну и не забываем, что есть способ путем задания правил механизма балансировки VMware DRS (однако, не у всех по лицензии DRS есть).

В этом способе есть один существенный минус - в то время, как он не позволяет пользователю двинуть виртуальную машину через vMotion вручную, смигрировать машину можно будет через перевод хоста ESXi в Maintenance mode, так как делается это не под аккаунтом пользователя, а под системной учетной записью (System). Но режим обслуживания используется редко, и хотя бы для ручных операций это можно будет сделать. Ну и имейте в виду, что механизм VMware HA также может перезапустить машину на другом хосте в случае сбоя, наплевав на все.

Итак, чтобы отключить vMotion для конкретной виртуальной машины, нужно создать новую роль (No-vMotion), для которой необходимо отключить привилегию по vMotion машины, назначатить эту роль администраторам и добавить пермиссию для виртуальной машины, указав юзеров с этой ролью (как работает этот механизм читайте здесь).

Итак, добавляем роль No-vMotion в vSphere Web Client:

1. Заходим в vCenter как administrator.
2. Идем на домашний экран и переходим в Roles на экране Administration.
3. Выбираем действие создать роль (зеленый плюс).
4. Выбираем "All Priveleges", скроллимся до категории "Resource" и отчекиваем следующие привилегии,

• Migrate powered off virtual machine
• Migrate powered on virtual machine
• Query vMotion

Далее добавляем пермиссию для виртуальной машины для нужного администратора/группы:

1. Выбираем "Host and Clusters" и находим нужную ВМ на вкладке Manage.
2. Выбираем пункт "Permissions" и кликаем на добавление пермиссии (зеленый плюс).
3. Нажимаем "Add" и выбираем пользователя или группу, которым мы хотим запретить vMotion этой виртуальной машины.
4. В правой части экрана выбираем роль "No-vMotion" и нажимаем "Ok".

Убеждаемся, что роль применена для данного пользователя к данному объекту (на остальные пермиссии это не повлияет):

Попробуем смигрировать эту виртуальную машину пользователем FrankD - видим, что опция "Migrate" загреена:

Но вот возможность перевода в Maintenance mode, к сожалению, по-прежнему активна:

Кто-нибудь знает более простой и надежный способ?

Не так давно мы писали о доступности бета-версии средства VMware Log Insight 2.0, предназначенного для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска. Вчера компания VMware анонсировала релизную версию VMware Log Insight 2.0.

Приведем здесь полный список новых возможностей решения Log Insight 2.0:

1. Улучшения производительности масштабируемости:

• VMware заявляет, что Log Insight работает в 6 раз быстрее конкурента - продукта Splunk.
• До 8 раз увеличена скорость сбора данных и до 6 раз - скорость выполнения запросов.
• До 2 ТБ анализируемых данных на узел.
• До 30% улучшения производительности отдельных узлов.
• Возможность масштабирования до 6 узлов при анализе данных.

2. Высокая доступность:

• Улучшения скорости обмена до 5-10 раз при работе в режиме Cluster mode.
• Нет единой точки отказа - при запросах можно использовать внешний балансировщик, перенаправляющий запросы к узлам. Появилась интеграция с решением vCenter Operations Management Suite.
• Единый интерфейс для работы со всеми данными узлов.

3. Проактивная аналитика:

• Обучаемая система типов событий и распознавания схем данных с интеллектуальной группировкой (близкие сообщения хранятся рядом).
• "Умные поля" в отчетах (распознается тип данных в поле).
• Сбор данных с таких продуктов VMware, как NSX, vCloud Automation Center, Horizon View.

4. Улучшенные дэшборды и графический интерфейс:

• Интерфейс на основе HTML 5.
• Простое добавление фильтров на лету.
• Возможность взаимодействия между разными виджетами одного дэшборда.
• Теперь работа с диаграммами стала намного удобнее (новые виды диаграмм, можно прятать колонки, можно добавлять чарты на дэшборд).

5. Поддержка RESTful API при работе с логами.

6. Улучшенные механизмы мониторинга собственного состояния.

7. Агент для сбора логов Windows:

• Перенаправляет Windows event logs.
• Мониторит изменения файлов журнала.
• Функции централизованной отчетности и управления логами.
• Потребляет мало ресурсов (до 5% CPU и 100-200 МБ оперативной памяти).
• Поддерживает автоматическую ротацию логов.

Кроме того, в скором времени будут доступны дополнительные контент-паки для следующих продуктов:

• Brocade SAN Content Pack – мониторит события с FC-коммутаторов Brocade, генерирует алерты
• Microsoft Active Directory Content Pack
• Microsoft Exchange Content Pack
• Microsoft Windows Content Pack

Дефолтный контент-пак для VMware vSphere содержит следующие представления:

• General – Overview
• General – Inventory
• General – Security
• vCenter – Alarms
• vCenter – Tasks
• ESXi
• DRS
• HA
• Networking
• Storage – Overview
• Storage – SCSI latency/errors
• Storage SCSI Sense Codes
• Storage – NFS
• Virtual Machine

Теперь лицензирование VMware Log Insight построено не на базе объема обрабатываемых данных, а на базе анализируемых систем (стоит это $200 за систему). Можно также купить лицензию на 1 физический процессор (CPU) сервера Log Insight.

Сам продукт VMware Log Insight 2.0 будет доступен для загрузки во втором квартале этого года. Более подробно о продукте можно узнать тут, а контент-паки можно загрузить отсюда.

Интересная новость пришла с конференции EMC World 2014, которая проходила с 5 по 8 мая в Лас-Вегасе. Теперь при построении распределенного ("растянутого") кластера VMware HA/DRS (он называется vSphere Metro Storage Cluster, vMSC) поддерживается задержка RTT (Round Trip Time) в канале до 10 миллисекунд. Для такого варианта использования сертифицировано решение VPLEX Geosynchrony 5.2, начиная с версии VMware vSphere 5.5.

Надо сказать, что технология EMC VPLEX Metro ранее поддерживалась на расстояниях между ЦОД в диапазоне до 100-150 км (иногда несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало. Теперь же это расстояние увеличилось до 300 километров.

Ранее технология vMotion поддерживалась и для latency до 10 мс, а вот механизм отказоустойчивости VMware HA гарантированно работал только для задержек до 5 мс.

При этом сейчас кластер vMSC сертифицирован как для нативного плагина доступа к хранилищам NMP (Native Multi-pathing), так и для плагина PowerPath/VE. Здесь надо обязательно отметить, что данная конфигурация поддерживается только издания VMware vSphere Enterprise Plus.

Более подробная информация о кластерах vMSC приведена в KB 2007545.

Мы много писали про функции ускорения 3D-графики в решении для виртуализации настольных ПК VMware View (например, тут и тут). Это режимы vSGA и vDGA, поддержка которых появилась еще в версии VMware View 5.2, но полноценно была добавлена только в версии VMware View 5.3. Ниже мы расскажем о некоторых аспектах использования этих режимов, опираясь на полезнейший документ "Graphics Acceleration in VMware Horizon View Virtual Desktops", где помимо теории даны и практические советы по настройке инфраструктуры для работы виртуальных машин в режимах vSGA и vDGA.

Итак, начнем с определений:

• Soft 3D - рендеринг 3D-картинки без использования адаптера на основе программных техник с использованием памяти сервера.
• vDGA - выделение отдельного графического адаптера (GPU) одной виртуальной машине.
• vSGA - использование общего графического адаптера несколькими виртуальными машинами.

Сразу отметим, что забота о поддержке режимов vDGA и vSGA лежит на плечах вендоров графических адаптеров. Пока этим в достаточной степени прославилась только компания NVIDIA.

Ниже рассмотрим картинку, на которой представлены варианты использования графических режимов для различных типов задач, которые предполагаются для работников, использующих виртуальные ПК:

Условно тут можно выделить 4 типа пользователей, касательно графически интенсивных нагрузок:

• Task Worker - обычный сотрудник (например, программист или менеджер по продажам), который не использует специальных графических программ и тяжелых нагрузок. Для него вполне подойдет софтверный рендер
• Knowledge Worker - этот человек имеет в своем распоряжении некоторое программное обеспечение, трубующее работы с графической подсистемой (например, иногда запускает Adobe Photoshop или смотрит видеоролики). Некоторым (в зависимости от частоты использования этих средств) вполне подойдет софтверный рендер, но кому-то будет нужная машина с поддержкой аппаратного рендеринга (но, скорее всего, в режиме vSGA).
• Desktop Power User - этот человек уже интенсивно работает с графическими пакетами, возможно, на нескольких мониторах. При этом используются графические библиотеки OpenGL или DirectX (но не самых последних версий).
• Workstation User - этот пользователь профессионально использует виртуальный десктоп для графически-интенсивных нагрузок (например, CAD-приложения или приложения для обработки и кодирования видео). Отличительная черта таких пользователей - профессиональное использование основного инструмента, требовательного к графике.

Соответственно, на диаграмме видно, когда и какой режим работы с графикой нужно использовать, в зависимости от категории пользователей. Практически это выглядит следующим образом: например, обычные офисные приложения вполне будут работать в режиме vSGA:

А вот некоторые пользователи тяжелых графических программ (например, Adobe Premiere) будут чувствовать себя комфортно только в режиме vDGA:

Режим vSGA

Идем дальше. Режим vSGA - это самый простой и эффективный способ использовать аппаратное ускорение для 3D-графики в виртуальных машинах. Он ограничивает системного администратора только объемом видеопамяти, которой, однако, у адаптера тоже не бесконечно много. На март этого года для режима vSGA поддерживаются следующие адаптеры:

• Nvidia GRID K1
• NvidiaGRID K2
• Nvidia Quadro 4000
• Nvidia Quadro 5000
• Nvidia Quadro 6000
• Nvidia Tesla M2070Q

В режиме vSGA есть три варианта использования:

• Automatic - аппаратное ускорение будет использовано только в случае доступного и подходящего GPU на хосте, где эта ВМ запущена. Если такого нет - то используется софтверный рендер. Когда машина переместится на подходящий хост - включится режим vSGA.
• Software only - всегда используется софтверный рендер (даже если есть свободные ресурсы GPU). Эта конфигурация работает на любом хосте.
• Hardware only - обязательное использование аппаратного ускорения. В этом случае проверяются условия при старте или миграции виртуальной машины на другой хост. Если они не выполняются - этого не происходит.
• Disabled - 3D-рендеринг не используется вовсе.

В плане драйвера гостевой ОС используется стандартный драйвер VMware SVGA 3D graphics. Но на сам ESXi нужно поставить специальные VIB-пакеты, которые будут обеспечивать работу виртуальных машин в режиме vSGA. Например, драйвер для ESXi 5.1 находится тут, а для ESXi 5.5 - тут.

Режим vDGA

Этот режим предназначен для случая, когда отдельный GPU нужно целиком и полностью отдать виртуальной машине. Этот режим основан на технологии VMware vSphere DirectPath I/O (то есть, прямой проброс устройств). Соответственно, здесь важно количество GPU на хосте VMware ESXi, которое и определяет максимальное количество запущенных виртуальных машин с поддержкой vDGA. Ну а максимальное число таких GPU на сервере определяется числом слотов PCIe x16 (нужно множить на число GPU у одного адаптера).

Например, на сервере Dell R720 может быть две карты NVIDIA GRID K2, каждая из которых имеет 2 GPU. Таким образом, максимальное количество виртуальных машин с поддержкой vDGA может быть четыре штуки.

В случае с vDGA используется драйвер от вендора, который и занимается работой с нижележащим оборудованием и видеокартой. На данный момент режим vDGA поддерживается для следующих графических адаптеров:

• Nvidia GRID K1
• Nvidia GRID K2
• Nvidia Quadro K2000
• Nvidia Quadro K4000
• Nvidia Quadro K5000
• Nvidia Quadro K6000
• Nvidia Quadro 1000M
• Nvidia Quadro 2000
• Nvidia Quadro 3000M
• Nvidia Quadro 4000
• Nvidia Quadro 5000
• Nvidia Quadro 6000
• Nvidia Tesla M2070Q

Кстати, при использовании таких адаптеров нужно учитывать электропитание серверов, так как, например, NVIDIA Quadro 6000 GPU использует до 200 Ватт мощности.

Если объединить специфику режимов софтверного рендера, vSGA и vDGA получится вот такая табличка:

Тут надо отметить, что как для vSGA, так и для vDGA режимов поддерживаются только гостевые ОС Windows 7 (для vSGA - x86 и x64, для vDGA - только x64).

Текущее выделение графических адаптеров и режим их работы можно проверить следующей командой на сервере VMware ESXi:

# gpuvm

Вывод будет примерно таким:

# gpuvm
Xserver unix:0, GPU maximum memory 2076672KB
pid 118561, VM “Test-VM-001”, reserved 131072KB of GPU memory
pid 664081, VM “Test-VM-002”, reserved 261120KB of GPU memory
GPU memory left 1684480KB

За дальнейшими подробностями можно проследовать в документ "Graphics Acceleration in VMware Horizon View Virtual Desktops".

Мы уже очень много писали про технологию VMware VSAN, которая позволяет создать кластер из локальных хранилищ хостов VMware ESXi (например, последнее - тут, тут и тут). На днях стало известно, что 10 марта состоится релиз этого решения, которое будет поставляться как дополнение к VMware vSphere, либо как предустановленное решение на брендовых серверах.

VSAN - один из самых серьезных и сложных продуктов VMware. В его тестировании приняло участие более 12 тысяч пользователей, и вот версия 1.0 уже почти готова.

Какие особенности будут у финальной версии VMware Virtual SAN:

• Технологию Virtua SAN будет поддерживать новый релиз платформы виртуализации vSphere 5.5 Update 1, который, очевидно, будет выпущен вместе с VSAN. Также будет поддерживаться и решение VMware Horizon View.
• Апгрейд бета-версий VSAN на релизную версию поддерживаться не будет.
• Стоимость и комплектация изданий будут известны вместе с выходом продукта 10 марта.
• Обещают, что производительность кластера VSAN будет масштабироваться линейно по мере роста количества узлов в нем.
• В кластере хранилищ VSAN поддерживается до 32-х узлов. Минимально нужно 3 хоста ESXi.
• На одном узле поддерживается работа до 100 виртуальных машин. Всего, таким образом, получается до 3200 машин в кластере.
• Для работы кластера на каждом узле должны быть как SSD-диски (как минимум один), так и HDD-накопители. Если чего-то из этого нет - работать не будет.
• Максимально на одном узле поддерживается до 35 HDD-дисков и до 5 SSD-дисков (один SSD на 7 HDD, то есть каждые 7 дисков обязательно требуют твердотельный диск емкостью около 0.1 от совокупной емкости этих HDD).
• Суммарно поддерживаемая емкость кластера = 35 дисков * 32 хоста = 4.4 петабайта хранилища.
• Где можно использовать VSAN (например): для VDI-инфраструктуры, среднекритичные нагрузки (Tier 2/3) и DR-сценарии (хранилища резервной площадки).
• Минимальная скорость адаптера на хосте ESXi - 1 Гбит, но чтобы все работало надежно, очень рекомендуется строить сеть на адаптерах 10 Гбит. А все потому, что репликация идет синхронно.
• Дедупликации пока не будет.
• Производители оборудования, такие как Dell, HP и Cisco будут поддерживать VSAN и серверы "VSAN Ready". Вот тут можно посмотреть на список совместимого с VSAN оборудования. В день релиза станут доступными аж 13 готовых к VSAN конфигураций.
• Ввод-вывод на узле кластера разгоняли до 2-х миллионов IOPS (IOmeter 100% read, 4KB block size, а также 640K IOPS с профилем нагрузки 70/30 read/write и 4KB block size).
• Многие видели, что поддерживается совместная работа технологии VSAN с некоторыми решениями VMware, такими как vSphere Replication. Теперь также будет поддерживаться vSphere Data Protection for backups, vMotion, DRS, HA и многое другое.

Ну что ж, ждем с нетерпением выхода этой штуки, которая может оказаться весьма полезной многим.

Не так давно мы писали о том, что компания VMware выпустила виртуальный модуль VOVA (vSphere OpenStack Virtual Appliance), предназначенный для интеграции с архитектурой OpenStack, которая представляет собой комплекс проектов свободного программного обеспечения, предназначенного для построения облачной инфраструктуры.

На днях же VMware выпустила небольшой документ "Getting Started with OpenStack and VMware vSphere", в котором описывается схема того, как использовать решение vSphere в качестве бэкэнда для компонентов Nova (контроллер вычислительных ресурсов) и Cinder (облачные блочные хранилища).

В указанном руководстве все опирается на виртуальный модуль VOVA с Linux-машиной, которая реализует все необходимые сервисы OpenStack.

Структура документа:

• Introduction
  • VMware vSphere
  • OpenStack
  • Using OpenStack with vSphere
    • OpenStack and vSphere: Conceptual Analogies
  • The VMware OpenStack Virtual Appliance
• Requirements
  • vSphere Requirements
    • vSphere Inventory: Single Datacenter
    • Cluster: Automated VMware vSphere Storage DRS
    • Storage: Shared
    • Networking
      • Port Groups and VLANs
      • ESXi Firewall
      • DHCP Server
• Installation
  • Importing VOVA
  • Configuring VOVA
  • Starting VOVA
  • Configuring the VMware vSphere Web Client Plug-in for OpenStack
• Managing OpenStack with the Horizon Web Interface
  • Logging In – Web
  • Logging In – SSH/CLI
  • Flavor of the Day
  • Launching an Instance
  • Accessing the Console for an Instance
  • Managing Storage
    • Adding Persistent Storage to an Instance
    • Removing Persistent Storage from an Instance
    • Adding the Persistent Storage to Another Instance
  • Network

Надо отметить, что виртуальный модуль VOVA официально не поддерживается со стороны VMware и предоставляется "as is".

На прошедшей не так давно конференции VMworld 2013 Europe компания VMware, среди прочего, анонсировала новые версии продуктов для управления, автоматизации и мониторинга ИТ-среды предприятия. Сегодня вышли финальные версии следующих решений:

• VMware vCenter Operations Manager 5.8 - средство комплексной визуализации производительности, ресурсов и работоспособности инфраструктуры, операционных систем и приложений. О нем в составе Operations Suite мы подробно писали вот тут.

• VMware vCloud Automation Center 6.0 - продукт для управления облачной инфраструктурой предприятия (SaaS, PaaS, IaaS) средствами единого решения, построенного поверх VMware vCloud Director (для IaaS-инфраструктуры) и разработанного на базе решения DynamicOps (бывший продукт Virtual Resource Manager, VRM). О нем мы уже писали вот тут.

Напомним основные новые возможности vCenter Operations Manager 5.8 (VCOPS):

• Monitor business critical applications - поддержка мониторинга бизнес-приложений, например, Microsoft Exchange Server и SQL Server.
• Monitor fiber channel storage - комплексный многоуровневый мониторинг FC-хранилищ.
• Monitor Hyper-v servers - полноценная поддержка мониторинга серверов Hyper-V.
• Monitor Amazon AWS services - поддержка мониторинга сервисов Amazon, включая EC2, Elastic Block Store, Elastic Map Reduce, Elastic Load Balancing и Auto Scaling Group средствами пакета AWS management pack. Данный MP работает совместно с Cloudwatch service (по REST API), предоставляемым Amazon.
• Поддержка средства VMware Log Insight для мониторинга инфраструктуры vCenter Operations Manager.

Release notes продукта vCenter Operations Manager 5.8 доступны по этой ссылке, а скачать его можно по этой.

Основные новые возможности vCloud Automation Center 6.0 (vCAC):

• Возможность для пользователей запрашивать различные приложения и отслеживать статус их развертывания (эта функция пришла из Application Director).
• Улучшенный механизм работы с политиками утверждения операций.
• Конечные пользователи могут откатывать системные обновления самостоятельно.
• Возможности связи решения со сторонними сервисами.
• Развертывание сервисов на базе политик.
• Новый Advanced Service Designer, предоставляющий обновленные средства проектирования пользовательских форм и рабочих процессов.
• Возможность интеграции с продуктом IT Business Management Standard Edition.
• Поддержка VMware vCloud Hybrid Service, в том числе выполнения административных задач с ВМ, размещенными там.
• Поддержка архитектуры OpenStack (в дополнение к существующим vSphere, vCloud Director, Amazon Web Services, Hyper-V, Kernel-based Virtual Machine, Citrix XenServer и различным интерфейсам управления физическими серверами).
• Доступ к виртуальным машинам через Remote Console.
• Поддержка динамического создания изолированных и маршрутизируемых сетей и балансировщиков нагрузки.
• Поддержка хранилищ VSAN для размещения виртуальных машин.
• Поддержка механизма Storage DRS.
• Поддержка служб LDAP.
• Улучшения Multi-tenancy (работа с несколькими организациями в одном окружении).
• Механизм Verb-oriented RESTFUL API в бета-версии.

Release notes продукта vCloud Automation Center 6.0 доступны по этой ссылке, а скачать его нельзя - надо связываться с VMware.

При каждом релизе платформы виртуализации VMware vSphere неизменно возникают вопросы о том, что же изменилось в плане поддержки гипервизором ESXi кластеров Microsoft Clustering Services (MSCS). Напомним, что базовая информация об этом находится здесь.

Вот какие варианты развертывания кластеров MSCS для различных приложений поддерживает VMware vSphere 5.5 (напомним, что о кластерах MSCS мы писали тут, тут и тут):

А вот какие версии и конфигурации кластеров Microsoft поддерживаются для различных верси гостевых ОС Windows Server и VMware vSphere:

А теперь перейдем к нововведениям, касающимся поддержки MSCS в VMware vSphere 5.5:

1. Во-первых, к общему хранилищу узлов кластера MSCS может быть организован доступ по нескольким путям посредством политики Round Robin (модуль PSP_RR). Ранее это сделать было нельзя ввиду проблем со SCSI reservations. Теперь эта проблема решена.

Однако тут есть ограничения:

• Поддерживается только для гостевых ОС Windows 2008 и Windows 2012.
• Поддерживаются только конфигурации Cluster Across Boxes (CAB) и N+1. Системы "Cluster in a box" (CIB) используют Virtual Reservations.
• Общий диск (Quorum или Data) должен быть развернут в режиме pass-through RDM.

2. Во-вторых, появилась поддержка протоколов FCoE & iSCSI. Ранее полноценно в качестве общего хранилища для кластеров MSCS поддерживались только  хранилища Fibre Channel, с оговорками iSCSI и как-то частично FCoE. Теперь же полноценно можно использовать iSCSI и FCoE хранилища.

А именно:

• Все конфигурации кластеров: CAB, CIB и N+1 поддерживаются iSCSI.
• Поддержка адаптеров iSCSI:
  
  • Software iSCSI;
  • Аппаратные адаптеры QLogic, Emulex и Broadcom.
• Поддержка режима Mixed mode для iSCSI-инициатора.
• До 5 узлов в кластере поддерживается для Windows 2008 SP2 и более поздних версий.

3. В-третьих, появилась поддержка кластеризации гостевых ОС Windows 2012 MSCS.

Если все это обобщить, то получится картинка, взятая отсюда:

Больше подробностей о поддержке MSCS в VMware vSphere 5.5 можно узнать из KB 2052238.

Мы уже писали про распределенный кэш на SSD-накопителях локальных дисков серверов ESXi, который имел рабочее название vFlash, а затем превратился в полноценную функцию VMware vSphere Flash Read Cache платформы VMware vSphere 5.5.

Сегодня мы хотим обратить внимание на два интересных документа, которые раскрывают подробности использования этой технологии.

Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение. Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.

Итак, первый документ о том как работает технология Flash Read Cache - "What’s New in VMware vSphere Flash Read Cache":

В этом документе описано, как работает инфраструктура vFlash в рамках виртуальной инфраструктуры vSphere, для каких целей можно использовать данную технологию, требования, а также шаги по установке и настройке этого механизма.

Второй документ - это официальный FAQ VMware по технологии Flash Read Cache - "VMware vSphere Flash Read Cache 1.0 FAQ". Так как она появилась впервые, и не все технические особенности ясны администраторам, в документе даны ответы аж на 67 вопросов.

Интересные факты из этого FAQ:

• В качестве интерфейсов накопителей поддерживаются SATA, SAS и PCI Express.
• До 8 устройств vFlash на один хост ESXi и до 4 ТБ емкости на устройство (до 400 ГБ на один VMDK). На один контейнер VFFS (то есть на хост) поддерживается до 32 ТБ.
• В качестве хранилищ ВМ механизмом поддерживаются тома VMFS/NFS/vRDM (pRDM не поддерживается).
• Настраивается только через Web Client.
• При изменении настроек vFlash все кэши для дисков сбрасываются.
• Thin provisioning не поддерживается технологией vFlash.
• При миграции виртуальной машины средствами vMotion можно использовать 2 политики: Always migrate the cache contents (copy) - кэш копируется вместе с ВМ и Do not migrate the cache contents (drop) - кэш очищается. Техники VMware HA / SVMotion также полностью поддерживается.
• Механизм VMware DRS при миграции не затрагивает машины с включенным Virtual Flash Read Cache.
• Операции, которые очищают кэш ВМ: suspend, изменение конфигурации, удаление, перезапуск машины или хоста, восстановление из снапшота. Операции, которые не очищают кэш: снятие снапшота, клонирование, миграция vMotion, fast suspend/resume.
• В vCenter есть 3 специальных метрики для мониторинга vFlash (IOPS, Latency и объем кэша).
• Кэшем vFlash можно управлять через ESX CLI: get –m <module> -c <cache file name>
• Файлы кэша vFlash находятся в следующей директории на хосте: /vmfs/volumes/vffs/vflash

Информацию об официально поддерживаемых механизмом VMware vSphere Flash Read Cache устройствах можно найти по этой ссылке: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vfrc

Сегодня на VM Guru день новостей об обучении. Заметкой выше мы написали о том, что компания Microsoft сделала ресурс Virtualization Square, который позволит ИТ-специалистам бесплатно не только пройти онлайн-обучение, но и сдать сертификационный экзамен.

Компания VMware, видимо будучи в курсе этой новости, объявила об обновлении своего портала vmwarewalkthroughs.com (о нем мы уже писали вот тут), на котором можно в интерактивном режиме пройти по шагам конфигурации различных продуктов в интерфейсе соответствующего решения.

Теперь на обучающем портале VMware добавились следующие демо решений:

• http://vmwarewalkthroughs.com/NSX/ 
  Наглядная конфигурация решения VMware NSX, эксклюзив, которого больше нигде не найти.
• http://vmwarewalkthroughs.com/vSOM/
  Показывается как настроить VMware vSphere HA, DRS, vSphere Replication, решение vCOPS и многое другое.
• http://vmwarewalkthroughs.com/vCloudSuite5-5/
  Информация о продуктах vCloud Director, App HA, Flash Read Cache и другое.
• http://vmwarewalkthroughs.com/VSAN/
  Как настроить хранилища VMware Virtual SAN, задать политики и прочее.

Для инженерного состава - самое то, чтобы начать знакомство с решениями VMware.

Наверное, почти все из вас знают, что сегодня открывается крупнейшая европейская конференция по виртуализации VMware VMworld Europe 2013, которая проходит в Барселоне. В период с 15 по 17 октября мы услышим немало интересных новостей и анонсов, которые VMware заботливо припасла еще с американской конференции (напомним, что анонсы VMworld 2013 мы описывали тут).

Вот наиболее интересные сессии на предстоящем VMworld 2103 Barcelona (надо сказать, что звездой программы будут продукты семейства vCenter Operations, кроме того нам расскажут про Fault Tolerance с поддержкой vSMP, то есть нескольких процессоров у ВМ):

• Oct 15 Tue 11am, VCM5539 – The Missing Link: Storage Visibility In Virtualized Environments
• Oct 15 Tue 3:30pm, BCO4977 – VMware vSphere Replication: Technical Walk-Through with Engineering
• Oct 16 Wed 2pm, VCM4992 – Tips and Tricks for Capacity Risk Assessment, Rightsizing and Planning
• Oct 16 Wed 2pm, VCM5811 – How to Manage vSphere and Hybrid Cloud with vCenter Operations Management
• Oct 16 Wed 2pm, STO5638 – Best Practices with Software Defined Storage 
• Oct 16 Wed 3pm, VCM5008 – vCenter Operations and the Quest for the Missing Metrics
• Oct 16 Wed 3:30pm, VCM5100 – How to Customize Your vCenter Operations Management Deployment for Your Specific Business Needs
• Oct 16 Wed 3:30pm, BCO5065 – VMware vSphere Fault Tolerance for Multiprocessor Virtual Machines – Technical Preview
• Oct 16 Wed 3:30pm, STO7449 – Tech Preview: Accelerating data operations Using VMware VVols and Storage Profile Based Management
• Oct 16 Wed 5pm, VCM5009 – Practical Real World Reporting with vCenter Operations
• Oct 17 Thu 9am, VCM4952 – Practicing What We Preach: VMware IT on  vCenter Operations Management Suite and vCloud Automation Center
• Oct 17 Thu 9am, NET5716 – Advanced VMware NSX Architecture
• Oct 17 Thu 10:30am, VSVC5280 – DRS: New Features, Best Practices and Future Directions
• Oct 17 Thu 12pm & 3pm, VCM5169 – How to troubleshoot VM performance issues across applications, infrastructure and storage using vCenter Operations Management(Live Demonstration!)
• Oct 17 Thu 1:30pm, VCM4981 – How to Identify if Your vSphere Environment is Configured to Meet Your Internal IT Standards
• Oct 17 Thu 1:30pm, VCM5781 – What’s New and What’s Next in vCenter Operations: A Tech Preview

Для тех, кто хочет своевременно выкачивать сессии в формате PDF, MP4 или MP3 (только аудиодорожка) есть вот такой скрипт. Просто подставляете туда свой логин и пароль с VMworld.com и тип загрузки контента.

Тем из вас, кого интересует технология кластеров хранилищ VMware vSAN будет интересно послушать следующие сессии:

• STO5391 - VMware Virtual SAN (Vijay Ramachandran and Christos Karamanolis)
• STO5027 - VMware Virtual SAN Technical Best Practices (Dinesh Nambisan and Cormac Hogan)
• EUC4688 - Lowering TCO for Virtual Desktops with VMware View and VMware Virtual SAN (Jad Chamcham and Narasimha Krishnakumar)
• STO4798 - Software-Defined Storage: The VCDX Way (Wade Holmes and Rawlinson Rivera)
• STO1004-GD - Software Defined Storage (VSAN, vFRC, Virsto) with Rawlinson Rivera, Cormac Hogan, Christos Karamanolis, and VMware R&D Engineers

Еще один список интересных сессий приведен вот тут.

Не так давно мы писали о технологии VMware VSAN, которая позволяет строить распределенные кластеры хранилищ на базе локальных дисков серверов VMware ESXi и которая была анонсирована на прошедшей конференции VMworld 2013. Напомним, что эта технология была куплена вместе с компанией Virsto Software (у нее русские корни, между прочим), и она на данный момент находится в статусе бета-версии. Эта штука умеет использовать локальные диски как источник хранения данных, а SSD-накопители - как кэш на чтение и буфер на запись.

На днях компания VMware выпустила интересный документ для тех, кто хочет немного вникнуть в архитектуру решения VMware VSAN - "What’s New in VMware Virtual SAN (VSAN)".

Документ содержит следующие секции:

• Introduction
• Requirements
• Install and Configure
• Architecture Details
• Storage Policy Based Management

Пример создания кластера VSAN представлен ниже - видно, что он поддерживает все распределенные службы VMware - HA, DRS, vMotion и прочее.

Создаваемые VSAN-хранилища управляются на базе политик, которые определяются правилами, например, избыточность в хостах или число дисковых страйпов:

Эти политики хранилищ можно назначать виртуальным машинам при создании, а также проверять различные сущности VMware vSphere на соответствие им. В общем, интересный документ - почитайте.

Мы уже не раз писали (тут и тут) про расширенные настройки (Advanced Settings) кластеров VMware HA в VMware vSphere (до версии 5.0 включительно). Эти настройки позволяют гибко настраивать различные параметры кластеров, их поведение, определять сетевые настройки и т.п. В этой статье мы приведем все эти настройки в единую таблицу и актуализуем для версии VMware vSphere 5.5.

Сразу после релиза обновленной версии платформы vSphere 5.5 компания VMware выпустила очень интересный и полезный документ Performance Best Practices for VMware vSphere 5.5, в котором рассматриваются аспекты производительности серверов VMware ESXi и виртуальных машин уже с учетом функциональности новой версии.

Например, теперь в документе описаны следующие фичи в контексте производительности:

• Функции кэширования на SSD-накопителях vSphere Flash Read Cache, о которых мы писали вот тут. Они увеличивают производительность за счет применения кэша на чтение для операций ввода-вывода виртуальных машин.
• Возможность VMware Virtual SAN (VSAN), о которой мы писали тут. Она позволяет использовать локальные ресурсы хостов ESXi для построения распределенной инфраструктуры хранения виртуальных машин.
• База данных VMware vFabric Postgres database (vPostgres).

Кроме того, были обновлены и дополнены следующие темы в документе (который уже можно смело называть книгой, так как занимает он 90 страниц):

• Использование нагрузок в ВМ, чувствительных к скорости подсистемы ввода-вывода и сетевому взаимодействию (интересна также статья в тему)
• Техники NUMA и Virtual NUMA (vNUMA)
• Техники экономии памяти хоста (Memory overcommit)
• Технология Large memory pages
• Техника Receive-side scaling (RSS), как в гостевых ОС, так и для адаптеров 10 Gigabit Ethernet
• Средства миграции VMware vMotion, Storage vMotion, а также Cross-host Storage vMotion
• Техники балансировки нагрузки VMware Distributed Resource Scheduler (DRS) и экономии электропитания Distributed Power Management (DPM)
• Обновленный (а точнее полностью переписанный) VMware Single Sign-On Server (об этом у нас тут)

Очень часто при чтении документации VMware приходиться сталкиваться с различного рода сокращениями, большинство из которых, конечно же, понятно опытным администраторам VMware vSphere, но не всегда понятно для новичков.

Andrea Mauro составил неплохой список акронимов VMware, который мы и публикуем здесь (ссылки добавил я - на релевантные статьи):

Если у вас есть что дополнить - пишите в каменты.

Интересны также другие посты на эту тему:

• VMware related acronyms (YellowBricks)
• VMware related Acronyms and Abbreviations (Virten)
• Abbreviations (VMware Directory)
• How to pronounce some of VMware’s acronyms

Последний пост о произношении акронимов особенно интересен. Например, vCAC произносится как "викейк" (v-cake), а vCHS как "вичес" (v-chess).

Продолжаем знакомить вас с анонсами VMworld 2013, среди которых было немало интересного. Как вы помните, у компании VMware в основном продуктовом портфеле есть решение VMware Site Recovery Manager, предназначенное для построения катастрофоустойчивой архитектуры на базе основной и резервной площадок. О предыдущей версии VMware SRM 5.1 мы уже писали вот тут. Ну а сегодня расскажем про VMware Site Recovery Manager 5.5.

Но сначала для тех, кто хочет знать, как об этом рассказывали на VMworld:

Напомним, что в SRM можно использовать репликацию на уровне дисковых массивов (array-based), которая работает быстро, надежно (до RPO=0) и синхронно (или асинхронно), но требует вложений в инфраструктуру, а также host-based репликацию по сети передачи данных, которая работает менее эффективно (RPO - от 15 минут до 24-х часов), зато использует существующую инфраструктуру Ethernet. О некоторых улучшениях host-based репликации в VMware vSphere 5.5 мы уже упоминали в этой статье.

Итак, что нового появилось в VMware SRM 5.5:

• Возможность протестировать процедуру аварийного восстановления с двух сторон, без нарушения работы производственного окружения.
• Поддержка виртуальных машин с дисками более 2 ТБ.
• Поддержка Windows Server 2012 для установки компонентов SRM.
• Новые настройки для поддержки режима vSphere Replicaiton.
• При перемещении машин в рамках одной consistency group полностью поддерживаются техники Storage DRS и Storage vMotion.
• Защита виртуальных машин, хранилища которых находятся на бэкэнде Virtual SAN (vSAN). Естественно, это реализовано на базе vSphere Replication.
• Поддержка техники multiple point-in-time (MPIT) - нескольких точек для восстановления целевой реплицируемой машины. Это защищает сервисы от логических повреждений данных, изменения в которых реплицируются на резервную площадку.
• SRM 5.5 больше не поддерживает базу данных IBM DB2.

Надо отметить, что для управления инфраструктурой SRM по-прежнему требуется "толстый" клиент vSphere Client (напомним, что его не убрали из vSphere 5.5, хотя и обещали - похоже именно из-за сопутствующих продуктов), а про поддержку vSphere Web Client пока ничего не говорят.

Интересной новой возможностью, о которой шла речь на VMworld, стал сценарий создания резервной инфраструктуры SRM в одном из поддерживаемых публичных облаков (он может быть использован как общий Recovery-сайт для нескольких филиалов компании):

Лицензирование продукта осталось прежним - либо за защищаемые виртуальные машины (если покупаем просто SRM), либо по процессорам хостов VMware ESXi (если покупаем в составе vCloud Suite).

О доступности для загрузки VMware Site Recovery Manager 5.5 будет объявлено несколько позднее.

Ну и помните (на всякий случай) предупреждение VMware:

Using SRM and vSphere Replication to replicate and recover virtual machines on VMware Virtual SAN datastores can results in incomplete replications when the virtual machines are performing heavy I/O. ESXi Server can stop  unexpectedly.

Кстати, в будущем нам обещают, что VMware SRM будет доступен в виде виртуального модуля (Virtual Appliance).

Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.

Как известно, инфраструктура виртуальных ПК всегда обладала такой особенностью, что приложения, требовательные к производительности 3D-графики, как правило не переносили в VDI-среду. Сначала эту парадигму начала изменять компания Citrix, которая продвигала концепцию виртуализации требовательных к графике нагрузок, опираясь на разработки компании NVIDIA VGX, о которых мы уже писали вот тут, тут и тут. Естественно, NVIDIA стала сотрудничать и с компанией VMware - лидера на рынке если и не VDI-решений, то уж точно платформ виртуализации.

Выпустив VMware Horizon View 5.2, компания VMware сделала серьезный шаг в направлении улучшения производительности 3D-графики в виртуальных десктопах. Теперь о возможностях отображения графики в виртуальных ПК можно говорить в разрезе трех техник:

• Soft 3D - рендеринг 3D-картинки вообще без использования адаптера на основе программных техник с использованием памяти сервера.
• vDGA - выделение графического адаптера (GPU) отдельной виртуальной машине.
• vSGA - использование общего графического адаптера несколькими виртуальными машинами.

Понятно, что режимы vDGA и vSGA должны поддерживаться со стороны производителя аппаратного обеспечения, что и предоставляет NVIDIA в своих графических адаптерах (информация актуальна для релиза VMware View 5.2):

Краткое сравнение обеих техник:

Рассмотрим эти режимы немного подробнее.

Soft 3D - графическая карта не нужна

В этом режиме сервер может работать без графического адаптера, при этом рендеринг картинки происходит программными средствами с использованием выделенной области оперативной памяти. Так сейчас работает большинство серверов и десктопов, которым не требуется особая производительность графики. При этом поддерживается программная обработка для приложений, работающих с DirectX 9 и OpenGL 2.1.

vDGA (Virtual Dedicated Graphics Adapter) - выделенный ВМ физический адаптер

В этом случае один GPU видеокарты выделяется только одной виртуальной машине, а его использование происходит посредством установленного в ней драйвера NVIDIA:

Надо отметить, что поскольку в этом режиме ВМ завязана на физическое устройство, то для нее не поддерживаются функции динамических сервисов, такие как HA, vMotion и DRS. Однако это лучший способ гарантировать виртуальной машине производительность.

vSGA (Virtual Shared Graphics Adapter) - общий GPU для нескольких виртуальных машин

В этом режиме один GPU через драйвер NVIDIA рендерит картинку сразу для нескольких виртуальных машин. Для этого режима используется специальный драйвер на уровне ядра VMware ESXi, который обрабатывает запросы нескольких виртуальных машин к одному адаптеру. Понятное, дело этот способ не гарантирует производительности, однако подходит для большинства инсталляций, в случаях, когда ВМ не требуется высокой и гарантированной производительности в области 3D-графики.

В консоли VMware View настройки графических режимов производятся на уровне пула виртуальных ПК. Видеопамять, выделяемая под ВМ, использует либо ресурсы памяти хост-сервера (это важно учитывать при сайзинге памяти для виртуальных машин на хосте), либо также его аппаратные графические ресурсы.

Все это уже сейчас есть и работает в VMware View 5.2 (об этом можно прочитать в документе Virtual Machine Graphics Acceleration Deployment Guide).

Был тут случай недавно - пишет мне товарищ, дескать, что это мы пост разместили с инфой, которая под NDA. А откуда мы должны знать, что находится под NDA, а что не под NDA? И вообще с какой стати все эти заморочки с NDA? Я вообще на тему продуктов чьих-то NDA никогда не подписывал и подписывать не собираюсь. А если появляется утечка с новыми возможностями продукта или компании - это никакой нахрен не слив инфы под NDA, а самая обычная и уже набившая оскомину реклама - радуйтесь.

Или вот приходит нам рассылка про новую версию vCloud Director, а внизу написано:

***** Confidential Information ***** 
Do not forward information about this program or release to anyone outside of those directly involved with beta testing. This information is highly confidential.

Information contained in this email, including version numbers, is not a commitment by VMware to provide or enhance any of the features below in any generally available product.

Или вот NVIDIA пишет:

Обращаю ваше внимание, что информация брифинга находится под NDA до 17:00 по Москве вторника, 23-го июля.

И чо? А если я им в письме напишу, что им нельзя мыться 3 месяца - они будут этот наказ соблюдать?

Так что, уважаемые вендоры, надеюсь, вам понятна позиция VM Guru с вашими NDA. Если мы их не подписывали - не пишите нам ничего на эту тему, так как эти письма отправляются прямиком в трэш по ключевому слову "NDA".

Вон у Apple тоже, конечно, утечки бывают, но в целом-то - хрен узнаешь, когда этот новый айфон выйдет. Поэтому в этом посте мы с удовольствием расскажем о новых возможностях VMware vSphere 5.5 на основе информации, взятой из сети интернет (также об этом есть на блоге Андрея и Виктора - http://vmind.ru/2013/08/15/chego-zhdat-ot-vmware-vsphere-5-5/). Естественно, не все из этих фичей могут оказаться в релизной версии, и это, само собой, не полный их список.

New OS Support

Наряду с поддержкой Windows 8.1 (ожидается в VMware View 5.5) будут поддерживаться последние релизы гостевых ОС Linux: Ubuntu, Fedora, CentOS, OpenSUSE и другие дистрибутивы.

VMware Hardware Version 10

Теперь появится новое поколение виртуального аппаратного обеспечения версии 10. Это добавит новых возможностей виртуальным машинам с точки зрения динамических сервисов виртуализации. Для редакции vSphere Enterprise Plus будет поддерживаться до 128 vCPU.

Administrative UI (Web Client)

Новая версия веб-клиента vSphere Web Client теперь является единственным средством управления инфраструктурой виртуализации.

• Улучшенный интерфейс, большое количество фильтров и вкладка "recent objects", позволяющая получить быстрый доступ к объектам.
• Улучшения по времени отклика интерфейса и возможность управлять большим числом объектов.

vSphere Replication - теперь доступны следующие возможности по репликации виртуальных машин:

• Возможность репликации виртуальных машин между кластерами для машин не с общими хранилищами (non-shared storage).
• Поддержка нескольких точек для восстановления целевой реплицируемой машины. Это защищает сервисы от логических повреждений данных, изменения в которых реплицируются на резервную площадку.
• Storage DRS Interoperability - возможность реплицируемых машин балансироваться по хранилищам средствами технологии Storage vMotion без прерывания репликации.
• Simplified Management - улучшенная интеграция с vSphere Web Client, что позволяет мониторить процесс репликации в различных представлениях vCenter.
• Поддержка технологии VSAN (см. ниже) - теперь машины на таких хранилищах поддерживаются средствами репликации.
• vCenter Orchestrator - теперь это средство автоматизации существенно оптимизировано в плане масштабируемости и высокой доступности. Разработчики теперь могут использовать упрощенные функции диагностики в vCenter Orchestrator client.

Virtual SAN

О возможностях VMware Distributed Storage и vSAN мы уже писали вот в этой статье. Virtual SAN - это полностью программное решение, встроенное в серверы VMware ESXi, позволяющее агрегировать хранилища хост-серверов (SSD и HDD) в единый пул ресурсов хранения для всех хостов, что позволяет организовать ярусность хранения с необходимыми политиками для хранилищ.

Поддержка томов vVOL

Также мы писали о поддержке виртуальных томов vVOL - низкоуровневых хранилищ для каждой из виртуальных машин, с которыми будут позволены операции на уровне массива, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Проще говоря, VMDK-диск машины можно будет хранить как отдельную сущность уровня хранилищ в виде vVOL, и с ней можно будет работать отдельно, без влияния на другие ВМ этого массива.

VMware Virtual Flash (vFlash)

О возможностях VMware Virtual Flash (vFlash) мы уже писали вот в этой статье. vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.

Virtual Machine File System (VMFS)

Теперь VMware vSphere 5.5 поддерживает vmdk-диски объемом более 2 TБ. Теперь объем виртуального диска машины может быть размером до 64 ТБ. Несколько больших файлов теперь могут храниться в одном vmdk. Это поддерживается только для VMFS 5.

vCloud Director

Теперь продукт доступен как виртуальный модуль (Virtual Appliance) - можно использовать как встроенную так и внешнюю БД. Этот модуль по-прежнему не будет рекомендован для продакшен-среды. Рекомендуют использовать его для апробации решения.

Был существенно улучшен Content Catalog:

• Улучшена производительность и стабильность синхронизации
• Расширяемый протокол синхронизации
• Возможность самостоятельной загрузки элементов каталога (OVF)

Кроме того, для интерфейса управления теперь поддерживается больше браузеров и ОС (в том числе поддержка Mac OS).

vCloud Networking & Security

В составе vSphere 5.5 этот продукт будет иметь следующие улучшения:

• Улучшенная поддержка Link Aggregation Control Protocol (LACP) - теперь поддерживается 22 алгоритма балансировки и до 32 физических соединений в агрегированном канале.
• Улучшения производительности и надежности агрегированного канала.

Кроме того, вместо vCloud Networking and Security с октября выходит новый продукт VMware NSX.

Security Features

Теперь появится распределенный сетевой экран (Distributed Firewall), являющийся одним из ключевых компонентов концепции Software Defined Datacenter. Он работает на уровне гипервизора каждого из хостов VMware ESXi, а на уровне централизованной консоли доступен мониторинг проходящих пакетов от абсолютно каждой виртуальной машины.

Политики этого сетевого экрана определяются на уровне VXLAN, поэтому нет нужды оперировать с ним на уровне IP-адресов. Ну и так как поддержка этого распределенного фаервола реализована на уровне гипервизора - то политики перемещаются вместе с виртуальной машиной, если она меняет хост средствами vMotion.

Более подробно об этом можно прочитать тут.

vCenter Site Recovery Manager

Теперь vCenter SRM будет поддерживать технологию vSAN вместе с vSphere Replication, работать с технологиями Storage DRS и Storage vMotion. Кроме того, добавлена поддержка нескольких точек восстановления реплик (Multi-Point-In-Time snapshots) при исполнении плана аварийного восстановления.

VMware vCenter Multi-Hypervisor Manager (MHM) 1.1

Об этом продукте мы уже писали вот тут. Теперь он будет поддерживать гипервизор Microsoft Hyper-V 3.0 в Windows Server 2012 R2 (а также более ранние его версии). Также появилась возможность холодной миграции ВМ с хостов Hyper-V на VMware vSphere.

Single Sign-On 2.0 (SSO)

В новой версии единого средства аутентификации продуктов VMware теперь появится улучшенная и новая поддержка следующих компонентов:

• vSphere
• vCenter Orchestrator
• vSphere Replication
• vSphere AppHA (новый продукт, который будет анонсирован на VMworld)
• vCloud Director
• vCloud Networking and Security (vCNS)

Технология VMware vDGA для VMware Horizon View 5.5

О технологии NVIDIA VGX мы уже писали вот тут, тут и тут. Согласно этой презентации, уже скоро мы увидим возможности шаринга и выделение GPU отдельным виртуальным машинам:

Ну что знал - рассказал. В целом, ничего революционного. Поддержку Fault Tolerance для 4-х vCPU обещают в VMware vSphere 6.0.

Виктору спасибо за ссылки. Вот еще немного о предстоящем выходе обновленной платформы - http://vmind.ru/2013/08/13/vmware-vsphere-5-5/.

Это гостевой пост компании ИТ-ГРАД - ведущего сервис-провайдера, предоставляющего услуги аренды виртуальных машин.

Для подавляющего большинства компаний наличие двух или более собственных площадок все еще остается непозволительной роскошью. И что же делать с обеспечением непрерывности оказания ИТ-сервисов в такой ситуации? Вывод очевиден: если по каким-то причинам нет возможности использовать публичное облако в качестве основной площадки - его можно использовать в качестве резервной!

С развитием облачных технологий все большее количество заказчиков готовы отказаться от собственной инфраструктуры в пользу высокодоступных сервисов по размещению виртуальных машин в публичном облаке.

Однако остаются ситуации, обусловленные спецификой деятельности компании, наличием уже осуществленных проектов по построению приватного облака, специфическими требованиями по производительности, безопасности и т.п., которые, возможно, временны, но не дают возможности воспользоваться публичным облаком для хостинга своих ИТ-сервисов.

• Возможно ли разместить резервную площадку в публичном облаке?
• С какими трудностями придется столкнуться при реализации проекта?
• И, в конце концов, сколько это будет стоить?

Такие вопросы все чаще возникают как на просторах сети, так и у потенциальных потребителей наших облачных услуг.

Читать дальше

На днях, на сайте проекта VMware Labs (у нас есть тэг Labs) появилась новая утилита DRMdiagnose, с помощью которой возможно просмотреть информацию о текущем состоянии ресурсов кластера и получить рекомендации по управлению ими.

DRM - это Distributed Resource Manager, основной компонент VMware vSphere, являющийся ядром механизма VMware DRS, который осуществляет балансировку ресурсов в кластере. Основное назначение утилиты DRMdiagnose - это предоставление информации о том, что произойдет с производительностью виртуальных машин и их вычислительными ресурсами, если настройки ресурсов (limit, shares, reservation) будут изменены для какой-то из виртуальных машин. Кроме того, эта утилита выдает рекомендации относительно того, что нужно сделать с ресурсами виртуальных машин по отношению к текущим назначенным ресурсам (уменьшить, увеличить).

Появилась эта утилита по той причине, что пользователи VMware vSphere не знали, что происходит с кластером и его производительностью при регулировании настроек выделения ресурсов для виртуальных машин. Утилита позволяет получить рекомендации относительно того, как можно изменить настройки ресурсов ВМ для достижения оптимальной производительности.

DRMdiagnose позволяет увидеть рекомендации в кластере наподобие таких:

Increase CPU size of VM Webserver by 1
Increase CPU shares of VM Webserver by 4000
Increase memory size of VM Database01 by 800 MB
Increase memory shares of VM Database01 by 2000

Decrease CPU reservation of RP Silver by 340 MHz
Decrease CPU reservation of VM AD01 by 214 MHz
Increase CPU reservation of VM Database01 by 1000 MHz

Для того, чтобы начать пользоваться DRMdiagnose, нужно скопировать в рабочую папку с утилитой снапшот кластера (drmdump), содержащий информацию о виртуальных машинах и их запросы на вычислительные ресурсы. Находится он вот тут:

• vCenter server appliance: /var/log/vmware/vpx/drmdump/clusterX/
• vCenter server Windows 2003: %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
• vCenter server Windows 2008: %ALLUSERSPROFILE%\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\

Сама утилитка может работать в трех режимах:

1. Default - если указан путь к drmdump, то выводятся все ВМ кластера, их назначенные ресурсы, а также запрашиваемые ресурсы.
2. Guided - если указан путь к drmdump и целевые параметры ресурсов ВМ, то утилита сгенерирует набор рекомендаций для их достижения.
3. Auto - если указан путь к drmdump, то будут сгенерированы рекомендации для самых несбалансированных ВМ (то есть ВМ, для которых разница между назначенными и запрашиваемыми ресурсами самая большая).

Выглядят снапшоты кластера вот так:

А вот так можно запустить утилиту в дефолтном режиме для вывода информации в файл output.txt:

Формат использования DRMdiagnose:

Работает DRMdiagnose только с VMware vCenter 5.1 и выше, скачать утилиту можно по этой ссылке.

Компания VMware выпустила интересный и полезный документ "Best Practices for Running VMware vSphere on Network-Attached Storage (NAS)", в котором описаны лучшие практики по работе платформы VMware vSphere на IP-хранилищах NAS/NFS, а также рекомендации по их развертыванию.

В документе рассмотрены различные варианты подключения дисковых массивов NFS, их преимущества и недостатки, а также совместная работа с такими технологиями как Storage I/O Control, VAAI, Network I/O Control, Storage DRS и прочими. Также администраторам будет интересно прочитать про расширенные настройки VMware vSphere, относящиеся к хранилищам NFS.

Duncan и Frank, известные своими изысканиями в сфере механизмов отказоустойчивости (HA) и балансировки нагрузки (DRS) в виртуальной инфраструктуре VMware vSphere, опубликовали пару интересных материалов, касающихся настройки среды vCloud Director и механизма Storage DRS.

Как вы знаете, в настройках кластера хранилищ (Datastore Cluster) есть галка, которая определяет, будут ли виртуальные диски VMDK машин обязательно находиться на одном хранилище (Datastore) при миграции средствами механизма Storage DRS:

Надо отметить, что галка Keep VMDKs together by default - это не совсем простая для понимания галка. Если ее не поставить, то действовать будет обратное - диски виртуальной машины будут обязательно размещаться на разных хранилищах. Это, по заверениям блоггеров, даст больше гибкости в использовании механизма SDRS в среде vCloud Director при перемещении виртуальных машин между хранилищами, что даст больше преимуществ в динамически балансирующейся среде (особенно для "тонких" дисков). Соответственно, по умолчанию галка Keep VMDKs together by default должна быть выключена.

Отличный пост про симулятор сервера vCenter написал William Lam. Изложим здесь его вкратце. Когда-то два человека, Zhelong Pan и Kinshuk Govil, написали утилиту vcsim, которая позволяет эмулировать сервер VMware vCenter в котором запущены тысячи виртуальных машин, при этом такие объекты потребляют минимум ресурсов и работают на минимальной конфигурации VMware vCSA (vCenter Server Appliance). Утилита входит в состав vCSA, но отсутствует в обычной инсталляции vCenter.

Помимо собственно построения виртуального Inventory сервера vCenter из виртуальных машин и хост-серверов, утилита vcsim поддерживает простейшие операции с фейковыми объектами, например, Power On ненастоящих машин, а также различные метрики производительности. Кроме того, с помощью этой утилиты можно и добавлять настоящие серверы VMware ESXi и виртуальные машины, создавая гибридную конфигурацию, так как vcsim - это, все же, настоящий vCenter Server.

Теперь приведем ситуации, когда такая конфигурация может оказаться полезной:

• При изучении vSphere API для исследования функций навигации по иерархии.
• Возможность создать "виртуальное" окружение для тестирования различных скриптов.
• Разработка утилит, отслеживающих производительность
• Разработка плагинов к vSphere Web Client 

Для начала работы с vcsim нужно внести изменения в файл /etc/vmware-vpx/vpxd.cfg, поместив туда следующее между тэгами </vpxd> и </config>:

<simulator>
<enabled>true</enabled>
<cleardb>false</cleardb>
<initinventory>vcsim/model/initInventory.cfg</initInventory>
</simulator>

Кстати, шаблон конфигурации vcsim представлен в файле:

/etc/vmware-vpx/vcsim/model/vcsim.cfg.template

После этого нужно перезапустить сервис vCenter:

service vmware-vpxd restart

Такой перзапуск сервиса можно делать только один раз (даже если он был не успешен), дальше будут использоваться другие команды, приведенные ниже.

После рестарта сервиса мы можем увидеть окружение с сотнями хост-серверов и десятью тысячами виртуальных машин, как в веб-клиенте:

\

так и в "толстом" клиенте:

Теперь мы можем менять параметры окружения в файле:

/etc/vmware-vpx/vcsim/model/initInventory.cfg

В нем можно настраивать следующие объекты:

• Datacenter
• Hosts per Datacenter
• VM per Host
• Powered On VM per Host
• Cluster per Datacenter
• Host Per Cluster
• Resource Pool per Cluster
• VM per Resource Pool
• Powered On VM
• vCPU for a VM
• vMEM for a VM

После того, как вы сохранили внесенные в конфигурацию изменения, нужно выполнить команду vpxd -b, чтобы пересоздать базу симулируемого vCenter. Поэтому выполняем следующую последовательность для рестарта сервиса:

service vmware-vpxd stop
vpxd -b
service vmware-vpxd start

Кроме того, vcsim использует следующие конфигурационные файлы:

• vcsim/model/metricMetadata.cfg (симулируемые Performance Metrics - по умолчанию их нет)
• vcsim/model/vcModules.cfg (симулируемые модули vCenter, например, DRS)
• vcsim/model/OperationDelay.cfg (задержки выполнения операций)

Так что теперь можно испытывать эту штуку и экспериментировать в свободное время. Ну и, само собой, все это никак не поддерживается со стороны VMware.

Для начала обратите внимание, что обновление вышло не для ESXi 5.1 (последней версии гипервизора), а для ESXi 5.0 - его предыдущей версии. Так что это обновление актуально только для тех, кто еще не успел переехать со старой версии платформы.

Помимо VMware ESXi 5.0 Update 2, вышел и VMware vCenter 5.0 Update 2. Новые возможности обновлений:

• Официальная поддержка работы vCenter 5.0 на Windows Server 2012.
• Официальная поддержка новых гостевых ОС: Oracle Solaris 11, Solaris 11.1, а также Mac OS X Server Lion 10.7.5.
• Поддержка сервером vCenter механизма Guest Operating System Customization для следующих гостевых ОС: Windows 8, Windows Server 2012, Ubuntu 12.04, RHEL 6.2, RHEL 6.3.
• Сервер vCenter Essentials больше не перехватывает лимит в 192 ГБ от старой модели лицензирования.
• Исправление ошибки, когда не работал таймаут SSH-сессии после выключения и включения сервиса SSH (хотя настройка сохранялась в конфиге).
• Исправление ошибки, когда в скриптовой установке не подхватывалось получение DNS-сервера хостом по DHCP, а вместо этого выставлялись ручные настройки.
• Исправление ошибки, когда при реинсталляции ESXi сохранялся лейбл локального датастора, который был задан ранее.
• Множественные багофиксы тут и тут, а также тут.

Скачать обновленные версии гипервизора ESXi 5.0 Update 2 и сервера vCenter 5.0 Update 2 можно по этой ссылке.

Для владельцев же новой версии VMware vSphere 5.1 также есть новости - вышел VMware vCenter 5.1b.

В основном этот релиз содержит множество исправлений ошибок, про которые можно прочитать вот тут. Наиболее значимые:

• Ошибки, связанные с истечением таймаутов при работе в VMware vSphere Client.
• Нельзя было залогиниться в vSphere Web Client как пользователь домена Active Directory с нестандартным UPN.

Скачать VMware vCenter 5.1.0b можно по этой ссылке.

Представляем вам очередную статью нового автора VM Guru - Максима Федотенко. В первой части статьи Максима "Рекомендации по защите инфраструктуры виртуальных десктопов, созданных на базе платформы VMware View" было рассказано о сетевой инфраструктуре в контексте безопасности VDI-решения. Во второй статье цикла речь пойдет о некоторых рекомендациях по настройкам серверов и служб технологической инфраструктуры VMware View.